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Abstract 


This document describes the View-based Access Control Model (VACM) 
for use in the Simple Network Management Protocol (SNMP) 
architecture. It defines the Elements of Procedure for controlling 
access to management information. This document also includes a 
Management Information Base (MIB) for remotely managing the 
configuration parameters for the View-based Access Control Model. 
This document obsoletes RFC 2575. 
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1. Introduction 


December 2002 


N 


DADA UA AHA A BW W 


Ke) 


The Architecture for describing Internet Management Frameworks 
[RFC3411] describes that an SNMP engine is composed of: 


AUNE 


a Dispatcher 

a Message Processing Subsystem, 
a Security Subsystem, and 

an Access Control Subsystem. 


) 
) 
) 
) 


Applications make use of the services of these subsystems. 


It is important to understand the SNMP architecture and its 
terminology to understand where the View-based Access Control Model 
described in this document fits into the architecture and interacts 


with other subsystems within the architecture. 


The reader is 


expected to have read and understood the description and terminology 
of the SNMP architecture, as defined in [RFC3411]. 


Wijnen, 


et al. Standards Track 


[Page 2] 


RFC 3415 VACM for the SNMP December 2002 


The Access Control Subsystem of an SNMP engine has the responsibility 
for checking whether a specific type of access (read, write, notify) 
to a particular object (instance) is allowed. 


It is the purpose of this document to define a specific model of the 
Access Control Subsystem, designated the View-based Access Control 
Model. Note that this is not necessarily the only Access Control 
Model. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119. 


1.2. Access Control 


Access Control occurs (either implicitly or explicitly) in an SNMP 
entity when processing SNMP retrieval or modification request 
messages from an SNMP entity. For example a Command Responder 
application applies Access Control when processing requests that it 
received from a Command Generator application. These requests 
contain Read Class and Write Class PDUs as defined in [RFC3411]. 


Access Control also occurs in an SNMP entity when an SNMP 
notification message is generated (by a Notification Originator 
application). These notification messages contain Notification Class 
PDUs as defined in [RFC3411]. 


The View-based Access Control Model defines a set of services that an 
application (such as a Command Responder or a Notification Originator 
application) can use for checking access rights. It is the 
responsibility of the application to make the proper service calls 
for access checking. 


1.3. Local Configuration Datastore 


To implement the model described in this document, an SNMP entity 


needs to retain information about access rights and policies. This 
information is part of the SNMP engine’s Local Configuration 
Datastore (LCD). See [RFC3411] for the definition of LCD. 


In order to allow an SNMP entity’s LCD to be remotely configured, 
portions of the LCD need to be accessible as managed objects. A MIB 
module, the View-based Access Control Model Configuration MIB, which 
defines these managed object types is included in this document. 
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2. Elements of the Model 


This section contains definitions to realize the access control 
service provided by the View-based Access Control Model. 


2.1. Groups 


A group is a set of zero or more <securityModel, securityName> tuples 
on whose behalf SNMP management objects can be accessed. A group 
defines the access rights afforded to all securityNames which belong 
to that group. The combination of a securityModel and a securityName 
maps to at most one group. A group is identified by a groupName. 


The Access Control module assumes that the securityName has already 


been authenticated as needed and provides no further authentication 
of its own. 


The View-based Access Control Model uses the securityModel and the 
securityName as inputs to the Access Control module when called to 
check for access rights. It determines the groupName as a function 
of securityModel and securityName. 


2.2. securityLevel 


Different access rights for members of a group can be defined for 
different levels of security, i.e., noAuthNoPriv, authNoPriv, and 
authPriv. The securityLevel identifies the level of security that 
will be assumed when checking for access rights. See the SNMP 

Architecture document [RFC3411] for a definition of securityLevel. 


The View-based Access Control Model requires that the securityLevel 


is passed as input to the Access Control module when called to check 
for access rights. 


2.3. Contexts 


An SNMP context is a collection of management information accessible 
by an SNMP entity. An item of management information may exist in 
more than one context. An SNMP entity potentially has access to many 
contexts. Details about the naming of management information can be 
found in the SNMP Architecture document [RFC3411]. 


The View-based Access Control Model defines a vacmContextTable that 
lists the locally available contexts by contextName. 
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2.4. MIB Views and View Families 


For security reasons, it is often valuable to be able to restrict the 
access rights of some groups to only a subset of the management 
information in the management domain. To provide this capability, 
access to a context is via a "MIB view" which details a specific set 
of managed object types (and optionally, the specific instances of 
object types) within that context. For example, for a given context, 
there will typically always be one MIB view which provides access to 
all management information in that context, and often there will be 
other MIB views each of which contains some subset of the 
information. So, the access allowed for a group can be restricted in 
the desired manner by specifying its rights in terms of the 
particular (subset) MIB view it can access within each appropriate 
context. 


Since managed object types (and their instances) are identified via 
the tree-like naming structure of ISO’s OBJECT IDENTIFIERs [ISO- 
ASN.1, RFC2578], it is convenient to define a MIB view as the 
combination of a set of "view subtrees", where each view subtree is a 
subtree within the managed object naming tree. Thus, a simple MIB 
view (e.g., all managed objects within the Internet Network 
Management Framework) can be defined as a single view subtree, while 
more complicated MIB views (e.g., all information relevant to a 
particular network interface) can be represented by the union of 
multiple view subtrees. 


While any set of managed objects can be described by the union of 
some number of view subtrees, situations can arise that would require 
a very large number of view subtrees. This could happen, for 
example, when specifying all columns in one conceptual row of a MIB 
table because they would appear in separate subtrees, one per column, 
each with a very similar format. Because the formats are similar, 
the required set of subtrees can easily be aggregated into one 
structure. This structure is named a family of view subtrees after 
the set of subtrees that it conceptually represents. A family of 
view subtrees can either be included or excluded from a MIB view. 


2.4.1. View Subtree 


A view subtree is the set of all MIB object instances which have a 
common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree 
is identified by the OBJECT IDENTIFIER value which is the longest 
OBJECT IDENTIFIER prefix common to all (potential) MIB object 
instances in that subtree. 
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2.4.2. ViewTreeFamily 


A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 
(called the family name) together with a bit string value (called the 
family mask). The family mask indicates which sub-identifiers of the 
associated family name are significant to the family’s definition. 


For each possible managed object instance, that instance belongs to a 
particular ViewTreeFamily if both of the following conditions are 
true: 


- the OBJECT IDENTIFIER name of the managed object instance contains 
at least as many sub-identifiers as does the family name, and 


- each sub-identifier in the OBJECT IDENTIFIER name of the managed 
object instance matches the corresponding sub-identifier of the 
family name whenever the corresponding bit of the associated 
family mask is non-zero. 


When the configured value of the family mask is all ones, the view 
subtree family is identical to the single view subtree identified by 
the family name. 


When the configured value of the family mask is shorter than required 
to perform the above test, its value is implicitly extended with 
ones. Consequently, a view subtree family having a family mask of 
zero length always corresponds to a single view subtree. 


2.5. Access Policy 


The View-based Access Control Model determines the access rights of a 
group, representing zero or more securityNames which have the same 
access rights. For a particular context, identified by contextName, 
to which a group, identified by groupName, has access using a 
particular securityModel and securityLevel, that group’s access 
rights are given by a read-view, a write-view and a notify-view. 


The read-view represents the set of object instances authorized for 
the group when reading objects. Reading objects occurs when 
processing a retrieval operation (when handling Read Class PDUs). 


The write-view represents the set of object instances authorized for 
the group when writing objects. Writing objects occurs when 
processing a write operation (when handling Write Class PDUs). 


The notify-view represents the set of object instances authorized for 


the group when sending objects in a notification, such as when 
sending a notification (when sending Notification Class PDUs). 
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the procedures followed by an Access Control 
the View-based Access Control Model when 

as requested by an application (for example a 
Notification Originator application). The 


abstract service primitive is: 


statusInformation = —- success or errorIndication 
isAccessAllowed ( 

securityModel -—- Security Model in use 
securityName —- principal who wants access 
securityLevel -- Level of Security 
viewType —- read, write, or notify view 
contextName -- context containing variableName 
variableName -- OID for the managed object 


) 


The abstract data elements are: 


statusInformatio 
accessAllowed 
not InView 


noSuchView 


noSuchContext 


noGroupName 


noAccessEntry 


otherError 
securityModel 
securityName - 
securityLevel 
viewType = 
contextName = 
variableName - 
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n- 


one of the following: 

a MIB view was found and access is granted. 
a MIB view was found but access is denied. 
The variableName is not in the configured 
MIB view for the specified viewType (e.g., in 
the relevant entry in the vacmAccessTable). 
no MIB view found because no view has been 
configured for specified viewType (e.g., in 
the relevant entry in the vacmAccessTable). 
no MIB view found because of no entry in the 
vacmContextTable for specified contextName. 
no MIB view found because no entry has been 
configured in the vacmSecurityToGroupTable 
for the specified combination of 
securityModel and securityName. 

no MIB view found because no entry has been 
configured in the vacmAccessTable for the 
specified combination of contextName, 
groupName (from vacmSecurityToGroupTable), 
securityModel and securityLevel. 

failure, an undefined error occurred. 


Security Model under which access is requested. 


the 


principal on whose behalf access is requested. 


Level of Security under which access is requested. 
view to be checked (read, write or notify). 
context in which access is requested. 

object instance to which access is requested. 
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3.1. Overview of isAccessAllowed Process 


The following picture shows how the decision for access control is 
made by the View-based Access Control Model. 


+-> securityModel -+ 


| | 
| | 
| (a) | 

who =+ +-> groupName ----+ 
| (1) | | (x) | | 
| +-> securityName --+ | | 
| (b) | | 
| | | 
| where -> contextName --------------------- $ | 
| (2) (e) | 
| | | 
| +-> securityModel ------------------- ; | 
| | (a) | | 
| Now +-> viewName -+ 

Od | (y) 

+-> securityLevel ------------------- + 

| (c) | +-> yes/no | 
| | | decision | 
| why ---> viewType (read/write/notify) ----+ | (z) 
| (4) (d) | | 
| what --> object-type ------ + | 
| (5) (m) | | | 
| +-> variableName (OID) ------ + 
| | (£) | 
| which -> object-instance --+ 

(6) (n) 
RE ESE Ne ae SE OEE EE AE OEE EE EELE O ETE EEE O k 
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How the decision for isAccessAllowed is made. 


1) 


Inputs to the isAccessAllowed service are: 


(a) securityModel —- Security Model in use 

(b) securityName —- principal who wants to access 
(c) securityLevel —- Level of Security 

(d) viewType -- read, write, or notify view 

(e) contextName -- context containing variableName 
(f) variableName —-- OID for the managed object 


-- this is made up of: 
- object-type (m) 
- object-instance (n) 


The partial "who" (1), represented by the securityModel (a) and 
the securityName (b), are used as the indices (a,b) into the 
vacmSecurityToGroupTable to find a single entry that produces a 
group, represented by groupName (x). 


The "where" (2), represented by the contextName (e), the "who", 
represented by the groupName (x) from the previous step, and the 
"how" (3), represented by securityModel (a) and securityLevel (c), 
are used as indices (e,x,a,c) into the vacmAccessTable to find a 
single entry that contains three MIB views. 


The "why" (4), represented by the viewType (d), is used to select 
the proper MIB view, represented by a viewName (y), from the 
vacmAccessEntry selected in the previous step. This viewName (y) 
is an index into the vacmViewTreeFamilyTable and selects the set 
of entries that define the variableNames which are included in or 
excluded from the MIB view identified by the viewName (y). 


The "what" (5) type of management data and "which" (6) particular 
instance, represented by the variableName (f), is then checked to 
be in the MIB view or not, e.g., the yes/no decision (z). 


Processing the isAccessAllowed Service Request 


This section describes the procedure followed by an Access Control 
module that implements the View-based Access Control Model whenever 
it receives an isAccessAllowed request. 


1) 


The vacmContextTable is consulted for information about the SNMP 
context identified by the contextName. If information about this 
SNMP context is absent from the table, then an errorIndication 
(noSuchContext) is returned to the calling module. 


Wijnen, et al. Standards Track [Page 9] 


RFC 3415 VACM for the SNMP December 2002 


2) 


The vacmSecurityToGroupTable is consulted for mapping the 
securityModel and securityName to a groupName. If the information 
about this combination is absent from the table, then an 
errorIndication (noGroupName) is returned to the calling module. 


The vacmAccessTable is consulted for information about the 
groupName, contextName, securityModel and securityLevel. If 
information about this combination is absent from the table, then 
an errorIndication (noAccessEntry) is returned to the calling 
module. 


a) If the viewType is "read", then the read view is used for 
checking access rights. 


b) If the viewType is "write", then the write view is used for 
checking access rights. 


c) If the viewType is "notify", then the notify view is used for 
checking access rights. 


If the view to be used is the empty view (zero length viewName) 
then an errorIndication (noSuchView) is returned to the calling 
module. 


a) If there is no view configured for the specified viewType, then 
an errorIndication (noSuchView) is returned to the calling 
module. 


b) If the specified variableName (object instance) is not in the 
MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in 
section 4), then an errorIndication (notInView) is returned to 
the calling module. 


Otherwise, 
c) The specified variableName is in the MIB view. A 


statusInformation of success (accessAllowed) is returned to the 
calling module. 
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4. Definitions 


SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= 


IMPORTS 
MODULE-COMPLIANCE, 


OBJECT-—GROUP 


VACM for the SNMP 


MODULE-IDENTITY, OBJECT-TYPE, 


snmpModules 
TestAndIncr, 


RowsStatus, 
SnmpAdminString, 
SnmpSecurityLevel, 
SnmpSecurityModel 


snmpVacmMIB 


LAST-UPDATED 


CONTACT-INFO 


Wijnen, 


et al. 


StorageType 


BEGIN 


FROM SNMPv2-CONF 


FROM SNMPv2-SMI 


FROM SNMPv2-TC 


December 2002 


FROM SNMP-FRAMEWORK-MIB; 


MODULE-IDENTITY 
"2002101600002" =a 
ORGANIZATION "SNMPv3 Working Group" 
snmpv3@lists.tislabs.com 
majordomo@lists.tislabs.com 
In message body: 


"WG-email: 


Subscribe: 


Co-Chair: 
postal: 
email: 
phone: 
Co-Chair: 


Postal: 


EMail: 
Phone: 


Co-editor: 


postal: 


email: 
phone: 


Co-editor: 


Russ Mundy 


Network Associates Laboratories 
15204 Omega Drive, 
MD 20850-4601 


Rockville, 
USA 


mundy@tislabs.com 


+1 301-947-710 


David Harringt 


Enterasys Networks 
35 Industrial Way 


P. O. Box 5004 
Rochester, 
USA 


dbh@enterasys.com 


+1 603-337-261 


Bert Wijnen 


16 Oct 2002, 


7 


on 


4 


midnight 


subscribe snmpv3 


Suite 300 


Lucent Technologies 


Schagen 33 


3461 GL Linschoten 


Netherlands 


bwijnen@lucent.com 


+31-348-480-68 


Randy Presuhn 
BMC Software, 


Standards Track 


5 


Inc. 


New Hampshire 03866-5005 
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DESCRIPTION 


VACM for the SNMP December 


postal: 2141 North First Street 
San Jose, CA 95131 
USA 
email: randy_presuhn@bmc.com 
phone: +1 408-546-1006 


Co-editor: Keith McCloghrie 
Cisco Systems, Inc. 


postal: 170 West Tasman Drive 
San Jose, CA 95134-1706 
USA 

email: kzm@cisco.com 

phone: +1-408-526-5260 


"The management information definitions for the 
View-based Access Control Model for SNMP. 


Copyright (C) The Internet Society (2002). This 
version of this MIB module is part of RFC 3415; 
see the RFC itself for full legal notices. 


" 


-- Revision history 


REVISION 
DESCRIPTION 


REVISION 
DESCRIPTION 


REVISION 
DESCRIPTION 


"2002101600002" -- 16 Oct 2002, midnight 
"Clarifications, published as RFC3415" 


"1999012000002" -—- 20 Jan 1999, midnight 
"Clarifications, published as RFC2575" 


"1997112000002" -- 20 Nov 1997, midnight 
"Initial version, published as RFC2275" 


::= { snmpModules 16 } 


2002 


= Administrative assignments KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmMIBObjects 


vacmMIBConformance OBJECT IDENTIFIER 


OBJECT IDENTIFIER ::= { snmpVacmMIB 1 } 
{ snmpVacmMIB 2 } 


— a Information about Local Contexts KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmContextTable OBJECT-TYPE 


SYNTAX 
MAX-ACCESS 
STATUS 


SEQUENCE OF VacmContextEntry 
not-accessible 
current 


DESCRIPTION "The table of locally available contexts. 


Wijnen, et al. 


This table provides information to SNMP Command 
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Generator applications so that they can properly 
configure the vacmAccessTable to control access to 
all contexts at the SNMP entity. 


This table may change dynamically if the SNMP entity 
allows that contexts are added/deleted dynamically 
(for instance when its configuration changes). Such 
changes would happen only if the management 
instrumentation at that SNMP entity recognizes more 
(or fewer) contexts. 


The presence of entries in this table and of entries 
in the vacmAccessTable are independent. That is, a 
context identified by an entry in this table is not 
necessarily referenced by any entries in the 
vacmAccessTable; and the context(s) referenced by an 
entry in the vacmAccessTable does not necessarily 
currently exist and thus need not be identified by an 
entry in this table. 


This table must be made accessible via the default 
context so that Command Responder applications have 
a standard way of retrieving the information. 


This table is read-only. It cannot be configured via 
SNMP. 


::= { vacmMIBObjects 1 } 


vacmContextEntry OBJECT-TYPE 


SYNTAX VacmContextEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION "Information about a particular context." 
INDEX { 
vacmContextName 


} 


::= { vacmContextTable 1 } 


VacmContextEntry ::= SEQUENCE 
{ 


vacmContextName SnmpAdminString 


} 


vacmContextName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS read-only 
STATUS current 
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DESCRIPTION "A human readable name identifying a particular 
context at a particular SNMP entity. 


The empty contextName (zero length) represents the 
default context. 


" 


:= { vacmContextEntry 1 } 


== Information about Groups KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmSecurityToGroupTable OBJECT-TYPE 


SYNTAX SEQUENCE OF VacmSecurityToGroupEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "This table maps a combination of securityModel and 
securityName into a groupName which is used to define 
an access control policy for a group of principals. 


::= { vacmMIBObjects 2 } 


vacmSecurityToGroupEntry OBJECT-TYPE 


SYNTAX VacmSecurityToGroupEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "An entry in this table maps the combination of a 
securityModel and securityName into a groupName. 


INDEX { 
vacmSecurityModel, 
vacmSecurityName 
} 


::= { vacmSecurityToGroupTable 1 } 


VacmSecurityToGroupEntry ::= SEQUENCE 
{ 
vacmSecurityModel SnmpSecurityModel, 
vacmSecurityName SnmpAdminString, 
vacmGroupName SnmpAdminString, 
vacmSecurityToGroupStorageType StorageType, 
vacmSecurityToGroupStatus RowStatus 


} 


vacmSecurityModel OBJECT-TYPE 


SYNTAX SnmpSecurityModel (1. .2147483647) 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The Security Model, by which the vacmSecurityName 
referenced by this entry is provided. 


Wijnen, et al. Standards Track [Page 14] 


RFC 3415 VACM for the SNMP December 2002 


Note, this object may not take the ’any’ (0) value. 


::= { vacmSecurityToGroupEntry 1 } 


vacmSecurityName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(1..32)) 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The securityName for the principal, represented ina 
Security Model independent format, which is mapped by 
this entry to a groupName. 


::= { vacmSecurityToGroupEntry 2 } 


vacmGroupName OBJECT-TYPE 
SYNTAX SnmpAdminString (SIZE(1..32)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The name of the group to which this entry (e.g., the 
combination of securityModel and securityName) 
belongs. 


This groupName is used as index into the 
vacmAccessTable to select an access control policy. 
However, a value in this table does not imply that an 
instance with the value exists in table vacmAccesTable. 


::= { vacmSecurityToGroupEntry 3 } 


vacmSecurityToGroupStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The storage type for this conceptual row. 
Conceptual rows having the value ’permanent’ need not 
allow write-access to any columnar objects in the row. 
" 

DEFVAL { nonVolatile } 

::= { vacmSecurityToGroupEntry 4 } 


vacmSecurityToGroupStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The status of this conceptual row. 


Until instances of all corresponding columns are 
appropriately configured, the value of the 
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corresponding instance of the vacmSecurityToGroupStatus 
column is /notReady’. 


In particular, a newly created row cannot be made 
active until a value has been set for vacmGroupName. 


The RowStatus TC [RFC2579] requires that this 
DESCRIPTION clause states under which circumstances 
other objects in this row can be modified: 


The value of this object has no effect on whether 
other objects in this conceptual row can be modified. 


" 
::= { vacmSecurityToGroupEntry 5 } 


a Information about Access Rights KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmAccessTable OBJECT-TYPE 


SYNTAX SEQUENCE OF VacmAccessEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The table of access rights for groups. 


Each entry is indexed by a groupName, a contextPrefix, 
a securityModel and a securityLevel. To determine 
whether access is allowed, one entry from this table 
needs to be selected and the proper viewName from that 
entry must be used for access control checking. 


To select the proper entry, follow these steps: 


1) the set of possible matches is formed by the 
intersection of the following sets of entries: 


the set of entries with identical vacmGroupName 
the union of these two sets: 
- the set with identical vacmAccessContextPrefix 
- the set of entries with vacmAccessContextMatch 
value of /’prefix’ and matching 
vacmAccessContextPrefix 
intersected with the union of these two sets: 
- the set of entries with identical 
vacmSecurityModel 
- the set of entries with vacmSecurityModel 
value of ’any’ 
intersected with the set of entries with 
vacmAccessSecurityLevel value less than or equal 
to the requested securityLevel 
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2) if this set has only one member, we’re done 
otherwise, it comes down to deciding how to weight 
the preferences between ContextPrefixes, 
SecurityModels, and SecurityLevels as follows: 

a) if the subset of entries with securityModel 
matching the securityModel in the message is 
not empty, then discard the rest. 

b) if the subset of entries with 
vacmAccessContextPrefix matching the contextName 
in the message is not empty, 
then discard the rest 

c) discard all entries with ContextPrefixes shorter 
than the longest one remaining in the set 

d) select the entry with the highest securityLevel 


Please note that for securityLevel noAuthNoPriv, all 
groups are really equivalent since the assumption that 
the securityName has been authenticated does not hold. 


" 


::= { vacmMIBObjects 4 } 


vacmAccessEntry OBJECT-TYPE 


SYNTAX VacmAccessEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "An access right configured in the Local Configuration 
Datastore (LCD) authorizing access to an SNMP context. 


Entries in this table can use an instance value for 
object vacmGroupName even if no entry in table 
vacmAccessSecurityToGroupTable has a corresponding 
value for object vacmGroupName. 
" 

INDEX { vacmGroupName, 

vacmAccessContextPrefix, 

vacmAccessSecurityModel, 

vacmAccessSecurityLevel 
} 


::= { vacmAccessTable 1 } 


VacmAccessEntry ::= SEQUENCE 
{ 

vacmAccessContextPrefix SnmpAdminString, 
vacmAccessSecurityModel SnmpSecurityModel, 
vacmAccessSecurityLevel SnmpSecurityLevel, 
vacmAccessContextMatch INTEGER, 
vacmAccessReadViewName SnmpAdminString, 
vacmAccessWriteViewName SnmpAdminString, 


Wijnen, et al. Standards Track [Page 17] 


RFC 3415 VACM for the SNMP December 2002 


vacmAccessNotifyViewName SnmpAdminString, 
vacmAccessStorageType StorageType, 
vacmAccessStatus Rowstatus 


} 


vacmAccessContextPrefix OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "In order to gain the access rights allowed by this 
conceptual row, a contextName must match exactly 
(if the value of vacmAccessContextMatch is ’exact’) 
or partially (if the value of vacmAccessContextMatch 
is ’prefix’) to the value of the instance of this 
object. 


::= { vacmAccessEntry 1 } 


vacmAccessSecurityModel OBJECT-TYPE 


SYNTAX SnmpSecurityModel 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "In order to gain the access rights allowed by this 
conceptual row, this securityModel must be in use. 


::= { vacmAccessEntry 2 } 


vacmAccessSecurityLevel OBJECT-TYPE 


SYNTAX SnmpSecurityLevel 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The minimum level of security required in order to 
gain the access rights allowed by this conceptual 
row. A securityLevel of noAuthNoPriv is less than 
authNoPriv which in turn is less than authPriv. 


If multiple entries are equally indexed except for 
this vacmAccessSecurityLevel index, then the entry 
which has the highest value for 
vacmAccessSecurityLevel is selected. 


" 


::= { vacmAccessEntry 3 } 


vacmAccessContextMatch OBJECT-TYPE 


SYNTAX INTEGER 
{ exact (1), -- exact match of prefix and contextName 
prefix (2) -- Only match to the prefix 


} 
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MAX-ACCESS read-create 

STATUS current 

DESCRIPTION "If the value of this object is exact(1), then all 
rows where the contextName exactly matches 
vacmAccessContextPrefix are selected. 


If the value of this object is prefix(2), then all 
rows where the contextName whose starting octets 
exactly match vacmAccessContextPrefix are selected. 
This allows for a simple form of wildcarding. 


DEFVAL { exact } 
::= { vacmAccessEntry 4 } 


vacmAccessReadViewName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The value of an instance of this object identifies 
the MIB view of the SNMP context to which this 
conceptual row authorizes read access. 


The identified MIB view is that one for which the 
vacmViewTreeFamilyViewName has the same value as the 
instance of this object; if the value is the empty 
string or if there is no active MIB view having this 
value of vacmViewTreeFamilyViewName, then no access 
is granted. 
" 

DEFVAL {ot A} -—- the empty string 

::= { vacmAccessEntry 5 } 


vacmAccessWriteViewName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The value of an instance of this object identifies 
the MIB view of the SNMP context to which this 
conceptual row authorizes write access. 


The identified MIB view is that one for which the 
vacmViewTreeFamilyViewName has the same value as the 
instance of this object; if the value is the empty 
string or if there is no active MIB view having this 
value of vacmViewTreeFamilyViewName, then no access 
is granted. 


DEFVAL { ''’H } -- the empty string 
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::= { vacmAccessEntry 6 } 


vacmAccessNotifyViewName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The value of an instance of this object identifies 
the MIB view of the SNMP context to which this 
conceptual row authorizes access for notifications. 


The identified MIB view is that one for which the 
vacmViewTreeFamilyViewName has the same value as the 
instance of this object; if the value is the empty 
string or if there is no active MIB view having this 
value of vacmViewTreeFamilyViewName, then no access 
is granted. 
" 

DEFVAL { ’'H } -—- the empty string 

::= { vacmAccessEntry 7 } 


vacmAccessStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The storage type for this conceptual row. 


Conceptual rows having the value ’permanent’ need not 


allow write-access to any columnar objects in the row. 
" 


DEFVAL { nonVolatile } 
::= { vacmAccessEntry 8 } 


vacmAccessStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The status of this conceptual row. 


The RowStatus TC [RFC2579] requires that this 
DESCRIPTION clause states under which circumstances 
other objects in this row can be modified: 


The value of this object has no effect on whether 
other objects in this conceptual row can be modified. 
" 


::= { vacmAccessEntry 9 } 


v Information about MIB views KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
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-—- Support for instance-level granularity is optional. 
-—- In some implementations, instance-level access control 
-- granularity may come at a high performance cost. Managers 


-- should avoid requesting such configurations unnecessarily. 


vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 } 


vacmViewSpinLock OBJECT-TYPE 


SYNTAX TestAndiIncr 
MAX-ACCESS read-write 
STATUS current 


DESCRIPTION "An advisory lock used to allow cooperating SNMP 
Command Generator applications to coordinate their 
use of the Set operation in creating or modifying 
views. 


When creating a new view or altering an existing 
view, it is important to understand the potential 
interactions with other uses of the view. The 
vacmViewSpinLock should be retrieved. The name of 
the view to be created should be determined to be 
unique by the SNMP Command Generator application by 
consulting the vacmViewTreeFamilyTable. Finally, 
the named view may be created (Set), including the 
advisory lock. 

If another SNMP Command Generator application has 
altered the views in the meantime, then the spin 
lock’s value will have changed, and so this creation 
will fail because it will specify the wrong value for 
the spin lock. 


Since this is an advisory lock, the use of this lock 
is not enforced. 


::= { vacmMIBViews 1 } 


vacmViewTreeFamilyTable OBJECT-TYPE 


SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "Locally held information about families of subtrees 
within MIB views. 


Each MIB view is defined by two sets of view subtrees: 
- the included view subtrees, and 
—- the excluded view subtrees. 

Every such view subtree, both the included and the 


Wijnen, et al. Standards Track [Page 21] 


RFC 3415 


Wijnen, 


et al. 


VACM for the SNMP December 2002 


excluded ones, is defined in this table. 


To determine if a particular object instance is in 

a particular MIB view, compare the object instance’s 
OBJECT IDENTIFIER with each of the MIB view’s active 
entries in this table. If none match, then the 
object instance is not in the MIB view. If one or 
more match, then the object instance is included in, 
or excluded from, the MIB view according to the 
value of vacmViewTreeFamilyType in the entry whose 
value of vacmViewTreeFamilySubtree has the most 
sub-identifiers. If multiple entries match and have 
the same number of sub-identifiers (when wildcarding 
is specified with the value of vacmViewTreeFamilyMask), 
then the lexicographically greatest instance of 
vacmViewTreeFamilyType determines the inclusion or 
exclusion. 


An object instance’s OBJECT IDENTIFIER X matches an 
active entry in this table when the number of 
sub-identifiers in X is at least as many as in the 
value of vacmViewTreeFamilySubtree for the entry, 
and each sub-identifier in the value of 
vacmViewTreeFamilySubtree matches its corresponding 
sub-identifier in X. Two sub-identifiers match 
either if the corresponding bit of the value of 
vacmViewTreeFamilyMask for the entry is zero (the 
‘wild card’ value), or if they are equal. 


A 'family’ of subtrees is the set of subtrees defined 
by a particular combination of values of 
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask. 


In the case where no /’/wild card’ is defined in the 
vacmViewTreeFamilyMask, the family of subtrees reduces 
to a single subtree. 


When creating or changing MIB views, an SNMP Command 
Generator application should utilize the 
vacmViewSpinLock to try to avoid collisions. See 
DESCRIPTION clause of vacmViewSpinLock. 


When creating MIB views, it is strongly advised that 
first the ’excluded’ vacmViewTreeFamilyEntries are 


created and then the ’included’ entries. 


When deleting MIB views, it is strongly advised that 
first the ’included’ vacmViewTreeFamilyEntries are 
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deleted and then the ’excluded’ entries. 


If a create for an entry for instance-level access 
control is received and the implementation does not 
support instance-level granularity, then an 
inconsistentName error must be returned. 


:= { vacmMIBViews 2 } 


vacmViewTreeFamilyEntry OBJECT-TYPE 


SYNTAX VacmViewTreeFamilyEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "Information on a particular family of view subtrees 
included in or excluded from a particular SNMP 
context’s MIB view. 


Implementations must not restrict the number of 
families of view subtrees for a given MIB view, 
except as dictated by resource constraints on the 
overall number of entries in the 
vacmViewTreeFamilyTable. 


If no conceptual rows exist in this table for a given 
MIB view (viewName), that view may be thought of as 
consisting of the empty set of view subtrees. 
" 
INDEX { vacmViewTreeFamilyViewName, 
vacmViewTreeFamilySubtree 
} 


::= { vacmViewTreeFamilyTable 1 } 


VacmViewTreeFamilyEntry ::= SEQUENCE 
{ 

vacmViewTreeFamilyViewName SnmpAdminString, 
vacmViewTreeFamilySubtree OBJECT IDENTIFIER, 
vacmViewTreeFamilyMask OCTET STRING, 
vacmViewTreeFamilyType INTEGER, 
vacmViewTreeFamilyStorageType StorageType, 
vacmViewTreeFamilyStatus RowStatus 


vacmViewTreeFamilyViewName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(1..32)) 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The human readable name for a family of view subtrees. 
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::= { vacmViewTreeFamilyEntry 1 } 


vacmViewTreeFamilySubtree OBJECT-TYPE 


SYNTAX 


MAX-ACCESS 


STATUS 


DESCRIPTION 


OBJECT IDENTIFIER 
not-accessible 
current 


"The MIB subtree which when combined with the 


corresponding instance of vacmViewTreeFamilyMask 
defines a family of view subtrees. 


::= { vacmViewTreeFamilyEntry 2 } 


vacmViewTreeFamilyMask OBJECT-TYPE 


SYNTAX 


MAX-ACCESS 


STATUS 


OCTET STRING (SIZE (0..16)) 
read-create 
current 


DESCRIPTION "The bit mask which, in combination with the 


Wijnen, et al. 


corresponding instance of vacmViewTreeFamilySubtree, 
defines a family of view subtrees. 


Each bit of this bit mask corresponds to a 
sub-identifier of vacmViewTreeFamilySubtree, with the 
most significant bit of the i-th octet of this octet 
string value (extended if necessary, see below) 
corresponding to the (8*i - 7)-th sub-identifier, and 
the least significant bit of the i-th octet of this 
octet string corresponding to the (8%*i)-th 
sub-identifier, where i is in the range 1 through 16. 


Each bit of this bit mask specifies whether or not 
the corresponding sub-identifiers must match when 
determining if an OBJECT IDENTIFIER is in this 
family of view subtrees; a ’1’ indicates that an 
exact match must occur; a ’0’ indicates ’/wild card’, 
i.e., any sub-identifier value matches. 


Thus, the OBJECT IDENTIFIER X of an object instance 
is contained in a family of view subtrees if, for 
each sub-identifier of the value of 
vacmViewTreeFamilySubtree, either: 


the i-th bit of vacmViewTreeFamilyMask is 0, or 
the i-th sub-identifier of X is equal to the i-th 
sub-identifier of the value of 


vacmViewTreeFamilySubtree. 


If the value of this bit mask is M bits long and 
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there are more than M sub-identifiers in the 
corresponding instance of vacmViewTreeFamilySubtree, 
then the bit mask is extended with 1’s to be the 
required length. 


Note that when the value of this object is the 
zero-length string, this extension rule results in 
a mask of all-1’s being used (i.e., no /’/wild card’), 
and the family of view subtrees is the one view 
subtree uniquely identified by the corresponding 
instance of vacmViewTreeFamilySubtree. 


Note that masks of length greater than zero length 
do not need to be supported. In this case this 
object is made read-only. 
" 

DEFVAL { ''H } 

::= { vacmViewTreeFamilyEntry 3 } 


vacmViewTreeFamilyType OBJECT-TYPE 


SYNTAX INTEGER { included(1), excluded(2) } 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "Indicates whether the corresponding instances of 
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask 
define a family of view subtrees which is included in 
or excluded from the MIB view. 

" 

DEFVAL { included } 

:= { vacmViewTreeFamilyEntry 4 } 


vacmViewTreeFamilyStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The storage type for this conceptual row. 


Conceptual rows having the value ’permanent’ need not 
allow write-access to any columnar objects in the row. 


DEFVAL { nonVolatile } 
::= { vacmViewTreeFamilyEntry 5 } 


vacmViewTreeFamilyStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The status of this conceptual row. 
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requires that this 


DESCRIPTION clause states under which circumstances 


other objects in this row can be modified: 


The value of this object has no effect on whether 
other objects in this conceptual row can be modified. 


{ vacmViewTreeFamilyEntry 6 } 


=o Conformance information KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmMIBCompliances 
vacmMIBGroups 


OBJECT IDENTIFIER 


OBJECT IDENTIFIER 


{ vacmMIBConformance 1 } 
{ vacmMIBConformance 2 } 


—— Compliance statements KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmMIBCompliance MODULE-COMPLIANCE 


STATUS 


current 


DESCRIPTION "The compliance statement for SNMP engines which 
implement the SNMP View-based Access Control Model 
configuration MIB. 


MODULE -- this module 


Wijnen, 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


et al. 


MANDATORY-GROUPS { vacmBasicGroup } 


vacmAccessContextMatch 
read-only 


"Write access is not required. 


vacmAccessReadViewName 
read-only 


"Write access is not required. 


vacmAccessWriteViewName 
read-only 


"Write access is not required. 


vacmAccessNotifyViewName 
read-only 


"Write access is not required. 


vacmAccessStorageType 
read-only 


"Write access is not required. 


vacmAccessStatus 
read-only 


"Create/delete/modify access to 
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vacmAccessTable is not required. 


OBJECT vacmViewTreeFamilyMask 
WRITE-SYNTAX OCTET STRING (SIZE (0)) 
MIN-ACCESS read-only 


December 


DESCRIPTION "Support for configuration via SNMP of subtree 


families using wild-cards is not 
" 


OBJECT vacmViewTreeFamilyType 
MIN-ACCESS read-only 
DESCRIPTION "Write access is not required." 


OBJECT vacmViewTreeFamilyStorageType 
MIN-ACCESS read-only 
DESCRIPTION "Write access is not required." 


OBJECT vacmViewTreeFamilyStatus 
MIN-ACCESS read-only 


required. 


DESCRIPTION "Create/delete/modify access to the 


vacmViewTreeFamilyTable is not required. 


{ vacmMIBCompliances 1 } 


2002 


—— Units of conformance KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmBasi 
OBJE 


STAT 
DESC 
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cGroup OBJECT-GROUP 

CTS { 
vacmContextName, 
vacmGroupName, 
vacmSecurityToGroupStorageType, 
vacmSecurityToGroupStatus, 
vacmAccessContextMatch, 
vacmAccessReadViewName, 
vacmAccessWriteViewName, 
vacmAccessNotifyViewName, 
vacmAccessStorageType, 
vacmAccessStatus, 
vacmViewSpinLock, 
vacmViewTreeFamilyMask, 
vacmViewTreeFamilyType, 
vacmViewTreeFamilyStorageType, 
vacmViewTreeFamilyStatus 

} 
US current 
RIPTION "A collection of objects providing for 
configuration of an SNMP engine which 
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END 


5: 


the SNMP View-based Access Control Model. 


::= { vacmMIBGroups 1 } 


Intellectual Property 
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7. Security Considerations 
7.1. Recommended Practices 
This document is meant for use in the SNMP architecture. The View- 


based Access Control Model described in this document checks access 
rights to management information based on: 


- contextName, representing a set of management information at the 
managed system where the Access Control module is running. 


- groupName, representing a set of zero or more securityNames. The 
combination of a securityModel and a securityName is mapped into a 
group in the View-based Access Control Model. 


- securityModel under which access is requested. 

- securityLevel under which access is requested. 

- operation performed on the management information. 

- MIB views for read, write or notify access. 

When the User-based Access Control module is called for checking 
access rights, it is assumed that the calling module has ensured the 


authentication and privacy aspects as specified by the securityLevel 
that is being passed. 


When creating entries in or deleting entries from the 
vacmViewTreeFamilyTable it is important to do such in the sequence as 
recommended in the DESCRIPTION clause of the vacmViewTreeFamilyTable 
definition. Otherwise unwanted access may be granted while changing 
the entries in the table. 


7.2. Defining Groups 


The groupNames are used to give access to a group of zero or more 
securityNames. Within the View-Based Access Control Model, a 
groupName is considered to exist if that groupName is listed in the 
vacmSecurityToGroupTable. 


By mapping the combination of a securityModel and securityName into a 


groupName, an SNMP Command Generator application can add/delete 
securityNames to/from a group, if proper access is allowed. 
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7. 


7. 


8. 


8. 


Further it is important to realize that the grouping of 
<securityModel, securityName> tuples in the vacmSecurityToGroupTable 
does not take securityLevel into account. It is therefore important 
that the security administrator uses the securityLevel index in the 
vacmAccessTable to separate noAuthNoPriv from authPriv and/or 
authNoPriv access. 


Conformance 


For an implementation of the View-based Access Control Model to be 
conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according 
to the vacmMIBCompliance. It also SHOULD implement the initial 
configuration, described in appendix A. 


Access to the SNMP-VIEW-BASED-ACM-MIB 


The objects in this MIB control the access to all MIB data that is 
accessible via the SNMP engine and they may be considered sensitive 
in many environments. It is important to closely control (both read 
and write) access to these to these MIB objects by using 
appropriately configured Access Control models (for example the 
View-based Access Control Model as specified in this document). 
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Appendix A - Installation 


Rud 


Installation Parameters 


During installation, an authoritative SNMP engine which supports this 
View-based Access Control Model SHOULD be configured with several 


initial parameters. These include for the View-based Access Control 
Model: 
1) A security configuration 


2) 


3) 


The choice of security configuration determines if initial 
configuration is implemented and if so how. One of three possible 
choices is selected: 


- initial-minimum-security-configuration 
- initial-semi-security-configuration 


- initial-no-access-configuration 


In the case of a initial-no-access-configuration, there is no 
initial configuration, and so the following steps are irrelevant. 


A default context 

One entry in the vacmContextTable with a contextName of "" (the 

empty string), representing the default context. Note that this 

table gets created automatically if a default context exists. 
vacmContextName we 


An initial group 


One entry in the vacmSecurityToGroupTable to allow access to group 
“initial”. 


vacmSecurityModel 3 (USM) 
vacmSecurityName "initial" 
vacmGroupName "initial" 
vacmSecurityToGroupStorageType anyValidStorageType 
vacmSecurityToGroupStatus active 
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4) Initial access rights 
Three entries in the vacmAccessTable as follows: 


- read-notify access for securityModel USM, securityLevel 
"noAuthNoPriv" on behalf of securityNames that belong to the 
group "initial" to the <restricted> MIB view in the default 
context with contextName "". 


- read-write-notify access for securityModel USM, securityLevel 
"authNoPriv" on behalf of securityNames that belong to the 
group "initial" to the <internet> MIB view in the default 
context with contextName "". 


- if privacy is supported, read-write-notify access for 
securityModel USM, securityLevel "authPriv" on behalf of 
securityNames that belong to the group "initial" to the 
<internet> MIB view in the default context with contextName "". 


That translates into the following entries in the vacmAccessTable. 


- One entry to be used for unauthenticated access (noAuthNoPriv): 


vacmGroupName "initial" 
vacmAccessContextPrefix nt 
vacmAccessSecurityModel 3 (USM) 
vacmAccessSecurityLevel noAuthNoPriv 
vacmAccessContextMatch exact 
vacmAccessReadViewName "restricted" 
vacmAccessWriteViewName a 
vacmAccessNotifyViewName "restricted" 
vacmAccessStorageType anyValidStorageType 
vacmAccessStatus active 


- One entry to be used for authenticated access (authNoPriv) with 
optional privacy (authPriv): 


vacmGroupName "initial" 
vacmAccessContextPrefix ner 
vacmAccessSecurityModel 3 (USM) 
vacmAccessSecurityLevel authNoPriv 
vacmAccessContextMatch exact 
vacmAccessReadViewName "internet" 
vacmAccessWriteViewName "internet" 
vacmAccessNotifyViewName "internet" 
vacmAccessStorageType anyValidStorageType 
vacmAccessStatus active 
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5) Two MIB views, of which the second one depends on the security 


configuration. 


- One view, the <internet> view, 


for authenticated access: 


- the <internet> MIB view is the following subtree: 


"internet" (subtree 1.3.6.1) 


- A second view, the <restricted> view, 


for unauthenticated 


access. This view is configured according to the selected 


security configuration: 


- For the initial-no-access-configuration there is no default 
initial configuration, so no MIB views are pre-scribed. 


- For the initial-semi-secure-configuration: 


the <restricted> MIB view is the union of these subtrees: 


(a) "system" (subtree 
(b) "snmp" (subtree 
(c) "snmpEngine" (subtree 
(d) "SsnmpMPDStats" (subtree 
(e) "usmStats" (subtree 


PRP PR 
Oa el ais 


-3. 


WWW WwW 


DWNAAWA OA 


gal 


errre 
Pes wie 


Duce 


DAAN 


1 
1 
S36 
3 
3 


-1) [RFC3918] 
11) [RFC3918] 
10.2.1) [RFC3411] 
-11.2.1) [RFC3412] 
-15.1.1) [RFC3414] 


- For the initial-minimum-secure-configuration: 


the <restricted> MIB view is the following subtree. 
"internet" (subtree 1.3.6.1) 


This translates into the following "internet" entry in the 


vacmViewTreeFamilyTable: 


minimum-secure 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 1.32652 
vacmViewTreeFamilyMask be 


"internet" 


vacmViewTreeFamilyType 1 (included) 
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType 


vacmViewTreeFamilyStatus active 
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semi-secure 


"internet" 
T3601 
we 


1 (included) 


active 
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In addition it translates into the following "restricted" entries in 


the vacmViewTreeFamilyTable: 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


Change Log 


Changes made since RFC 2575: 


minimum-secure 
"restricted" 
143-641 

we 

1 (included) 
anyValidStorageType 
active 


semi-secure 
"restricted" 
La36al. 2e1 1 

wee 

1 (included) 
anyValidStorageType 
active 


"restricted" 
13.37.6712) LL 

wee 

1 (included) 
anyValidStorageType 
active 


"restricted" 

13 £60 41416 3.000 22icd: 
1 (included) 
anyValidStorageType 
active 


"restricted" 

1s B61 623% LA 21 
1 (included) 
anyValidStorageType 
active 


"restricted" 

13 2651643915 ole 
1 (included) 
anyValidStorageType 
active 


- Removed reference from abstract as per RFC-Editor guidelines 


- Updated references 


et al. 
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Changes made since RFC 2275: 


- Added text to vacmSecurityToGroupStatus DESCRIPTION clause to 
clarify under which conditions an entry in the 
vacmSecurityToGroupTable can be made active. 

- Added REVISION clauses to MODULE-IDENTITY 

- Clarified text in vacmAccessTable DESCRIPTION clause. 

- Added a DEFVAL clause to vacmAccessContextMatch object. 

- Added missing columns in Appendix A and re-arranged for 
clarity. 

- Fixed oids in appendix A. 

- Use the PDU Class terminology instead of RFC1905 PDU types. 

- Added section 7.4 about access control to the MIB. 

- Fixed references to new/revised documents 

- Fix Editor contact information. 

- fixed spelling errors 

- removed one vacmAccesEntry from sample in appendix A. 

- made some more clarifications. 

- updated acknowledgement section. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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